EDI may be defined as computer-to-computer exchange of business information using ‘approved’ formatting standards. Millions of companies around the world use EDI to conduct commerce. With EDI, organizations have been empowered to send virtually limitless kinds of structured messages to one another to facilitate the communication of any kind of business data from one organization to another in more efficient ways. In this regard, once setup properly, EDI messages can be used to automate a variety of communications to and from partners, business sub-units, buyers, etc., thereby substantially reducing the overhead associated with filling out paper forms, storing volumes of papers, etc. With EDI, for instance, an organization merely fills out an electronic form in a manner conforming to a pre-defined schema, and then the messaging, storage/record keeping and validation of the message(s) associated with the electronic form occurs automatically.
In current EDI messaging scenarios, which applies to both inbound messages (i.e., where a message is received by an organization) and to outbound messages (i.e., where a message is transmitted from an organization to an intended recipient of the message), a single message can be addressed for multiple parties, and multiple messages can be received from different parties. EDI messages can be represented in a native EDI compact file format, or as an extensible markup language (XML) file, and there are known ways of transforming from EDI flat files to XML representations, and vice versa. EDI data is transmitted as delimited files (without self describing tags) and therefore the encoding rules enforce very strict formatting rules to ensure the destination application is able to successfully parse and consume the information for down stream processing.
As alluded to above, EDI messages have an associated EDI schema that instructs an EDI system how to interpret a given EDI message instance, i.e., how to validate an EDI message has been structured correctly and with appropriate information. For instance, when an EDI message of a particular type, e.g., a purchase order, is created by an EDI system, the EDI message is created in a way that conforms to the purchase order schema. Today, XML Schema Definitions (XSDs), external data representations (XDRs) and document type definitions (DTDs) are typically used to represent schemas for EDI messages. In this regard, XSDs, XDRs and DTDs are schema files that can be created to describe the schema for a particular kind of EDI message. Today, these XSD, XDR and DTD files are stored as individual files that are used in connection with the validation and generation of EDI messages in an EDI system.
When an organization is maximizing the value of EDI messaging, however, the organization might thus be storing numerous schemas on behalf of the EDI system. Once the number of schemas starts to exceed a few dozen, for instance, the storage requirements and management of those schemas can become non-trivial. This is for a number of reasons beyond the mere complexity of the problem due to excessive numbers of schema.
For instance, schemas evolve over time according to different versions, however, there is presently no support in current EDI systems for versioning of EDI schemas that evolve or otherwise change over time. An old schema must be replaced by a new schema in such case without retention of a versioning understanding by the system.
Additionally, many EDI elements that compose EDI schemas are represented in multiple schemas repeatedly, and yet no re-use of those EDI elements is presently possible. In this regard, there are thousands of EDI message types, also called transaction set definitions (TSDs). TSDs are composed of reusable units of items, which can be customized according to different business needs. Accordingly, it is desirable to have an EDI system that allows reuse of such units and manages their versioning.
Moreover, today's tools for viewing and editing an EDI schema file, e.g., as may be represented in an XSD file, display portions of the XSD file that do not pertain to the EDI elements represented by the XSD file. The problem with this is that today's tools do not have an understanding of the underlying nature of the TSD represented by the XSD file. Instead, today's tools display the entire XSD file to a user, which potentially leads to confusion because users are unable to filter out the unrelated XSD portions. They expect users to have a good understanding of XSDs, which is not desirable.
Accordingly, in consideration of the lack of sophistication of the current state of the art of the representation, storage, and management of EDI schemas in an EDI communications system, it would be desirable to provide improved tools and storage management systems for improved storage, management, reusability, versioning, editing, display and interaction with schemas in an EDI system. These and other deficiencies in the state of the art of EDI messaging will become apparent upon description of the various exemplary non-limiting embodiments of the invention set forth in more detail below.